企业互联网数据中台有哪些特点

企业互联网数据中台有以下特点：

• 能够借助汇聚全局的数据为用户赋能：数据本身就是能力，从某种程度上讲数据比上层的应用更重要，而且打通的全局数据所提供的价值将超过隔离的局部数据的总和。为了打通数据，在工具层，需要提供全局数据存储、治理分析服务以及数据/应用治理和管理的功能；在业务层，必须让每个业务部门能够方便地依据标准提供相关业务数据，自动与其他部门的数据打通并汇总。从这方面讲，这不是一个纯技术问题，更多的是一个业务问题。

• 实现数据能力的抽象：数据能力的抽象是数据中台建设中的难点，如何尽可能抽象出通用的功能，又不使抽象的功能过于细碎，这是需要仔细考虑的问题。这个问题有点类似于微服务的拆分，也与编程里抽象出对外API有着异曲同工之妙，拆大了不好，拆小了也有问题。前面我们提到过可以采用两种方式来进行数据能力的抽象：一种是顶层设计，从公司层面考虑数据能力的抽象；另一种是由业务团队自主开发，当发现有复用需要时再来抽象。这两种方式各有利弊，在很多时候可以混合使用，需要根据公司和业务的实际情况选择。

• 可以通过工具体系让企业各部门方便地共享抽象出的数据能力：首先，数据能力的共享必须简单，如果共享很麻烦，那么企业各部门数据的提供者和使用者就不会愿意使用这些功能，共享也就失去了意义。其次，共享的责权利必须要分清。这里涉及的角色有提供者、平台团队、使用者三方，而这三方的责权利划分。

• 能快速发现可复用的数据能力：这样才能在快速迭代时保证没有重复的开发，因为只有知道自己有什么轮子，才能避免重复造轮子。为了系统地避免重复开发的情况，一般需要有一定流程的支持。

• 能够协调复用和效率的矛盾：经常会出现这样的情况，团队A开发了一个功能，团队B觉得可以用，但是需要做些修改，而团队A暂时没有资源做这件事，团队B没有时间等，只能自己再开发一个。所以，关于共享功能的后续开发一定要有明确的规则和责权划分。

• 能够提高复用的效率：比如，如果团队A共享了一个功能后，其他部门的人天天来找团队A的人问这个功能怎么用，那么团队A的效率就会受到很大的影响。因此我们需要考虑共享功能的规范要求，例如共享的数据和应用的文档必须有一定要求。此外，共享的工具也必须提供迭代提升的功能，例如功能文档的协同编辑功能。